Well, I never liked the _u32 suffix, so agreed on that ;-)

For parameters that are known never to be negative, I would prefer either unsigned int or unsigned long. The difference is that unsigned long is guaranteed to contain at least 32 bit (even on MP-16BIT). So, if the API is expected to handle at least 32-bits on all platforms then unsigned long is better, otherwise unsigned int is better IMHO.

Thanks for doing this!

@nijtmans I also never liked a suffix for those functions (but I like them for the getters/setters).

Regarding unsigned - for now I want to keep it as int, like many other functions (eg mp_mul_2d etc). I want to separate the issues.
We can change this in a batch when we do #363. I see your point, but it is not without downsides. See what I wrote in #363.

@nijtmans I also never liked it for those functions (but I like them for the getters/setters).

Yes, for the getters/setters it's OK, agreed!

Regarding unsigned - for now I want to keep it as int, like many other functions (eg mp_mul_2d etc). I want to separate the issues.
We can change this when we do #363. I see your point, but it is not without downsides. See what I wrote in #363.

OK, understood! I'm aware of the downsides: It sure will have effect on the code, e.g. loops.

@nijtmans I assume on 32/64 bit archs? Why 28 exactly? Is this some magic width in tcl due to unboxed integers in the language runtime?

@nijtmans I assume on 32/64 bit archs? Why 28 exactly? Is this some magic width in tcl due to unboxed integers in the language runtime?

I don't know why the limit is exactly 28, but there is a test-case in Tcl's test-suite which checks whether pow(2^28) fails. Just try in Tcl (any version):

$ tclsh8.6
% expr 2**(2**28)
exponent too large
% expr 2**(2**27)
  (now it hangs ....)

Such exponentiation takes incredibly long to calculate ... So I see the reason for limiting the exponent to 28 bits, even with 27 bits it could be used for a DOS attack on Tcl (don't tell this to any hackers group, please ....)

Such exponentiation takes incredibly long to calculate

The exponentiation itself doesn't, it shouldn't take more than a couple of seconds, it is the number conversion that takes aeons. Even a well optimized program like Pari/GP needs over 15 seconds to convert 2^(2^27) to its over 40 million decimal digits. I don't know what our mp_to_radix would need—a couple of days maybe?

But don't worry, we are working at it in #330.

Indeed:

$ tclsh8.6
% expr 2**27;puts stdout
stdout
% expr 2**(2**27);puts OK
OK
%

A fraction of a second.

@sjaeckel your opinion on this? Do you have a better proposal?

closed in favor of #446